Intelligent Free-Time Search

ABSTRACT

Techniques are disclosed for performing free-time searches that exploit information of the type used with electronic calendars. By leveraging advanced calendaring system information and using location, other context information such as corporate policy, legal constraints, and technology constraints, and user-specific preferences to provide a complete picture of a person&#39;s availability, the functionality (and therefore the value) of scheduling systems in increased, resulting in an ability to schedule meetings with more accuracy and less rework. Various allowable participation types for meeting invitees may be specified, and each invitee&#39;s availability is determined accordingly. Location-sensitive travel times (including optional user-specific travel time adjustments) are used in preferred embodiments when in-person participation is required.

RELATED INVENTIONS

The present invention is related to the following commonly-assigned U.S.Patents: U.S. Pat. No. 6,988,128, titled “Calendar Events andCalendar-Driven Application Technique” (Ser. No. 09/670,844); U.S. Pat.No. 6,640,230, titled “Calendar-Driven Application Technique forPreparing Responses to Incoming Events” (Ser. No. 09/671,001); U.S. Pat.No. 7,035,865 titled “Calendar-Enhanced Awareness for Instant MessagingSystems and Electronic Status Boards” (Ser. No. 09/941,045); and U.S.Pat. No. 7,096,232, titled “Calendar-Enhanced Directory SearchesIncluding Dynamic Contact Information” (Ser. No. 09/875,556). Thedisclosures of these related inventions are hereby incorporated hereinby reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a computer system, and deals moreparticularly with methods, systems, and computer program products forperforming intelligent free-time searches (for example, to improvescheduling of meetings) of information such as that used with electroniccalendars.

2. Description of the Related Art

Calendars, and electronic calendars in particular, often contain awealth of information about their owner. For example, an individual mayuse an electronic calendar to maintain information about his workschedule, his meetings and other appointments, his vacation and businesstravel plans (including when he will be away, which flights or othertransportation he will use, where he can be reached while away, who hemay visit while away, etc.), phone calls that need to be made atparticular times, and so forth. Examples of electronic calendaringsystems include Microsoft Outlook® 2000 and Lotus Notes®. (“Outlook” isa registered trademark of Microsoft Corporation, and “Lotus Notes” is aregistered trademark of Lotus Development Corporation.)

Use of electronic calendaring systems for purposes such as schedulingmeetings of multiple persons is known in the art. For example, aninvitation list may be created for a particular meeting, and acalendaring software application may then use this list to check eachinvitee's calendar for available time periods. A meeting may then bescheduled during a time period in which all (or some majority) of theinvitees have sufficient time available on their calendar. However,prior art scheduling capabilities in calendaring systems havelimitations which can render them ineffective in many scenarios. Inparticular, scheduling meetings between multiple people using prior arttechniques is typically a time-consuming task that often involves manyiterations. It may either fail to accommodate considerations beyondrudimentary duration requirements or may require significant manualinput to handle such considerations, or it may find only unacceptablylate dates.

Scheduling capability in prior art electronic calendaring systems, whenpresent, is typically limited to a rudimentary “free-time search” whichonly looks for blocks of free time on the users' calendars. However,using just free time may generate results that are too constrained insome scenarios or results that are not constrained enough in otherscenarios. As an example of results that are too constrained when basedsolely on free time, it may be acceptable for a particular meeting tohave one or more of the invitees participate by phone (rather thanrequiring them to be present in person); these invitees might be willingto call in to the meeting from their cell phones while they arecommuting, or they might be willing to call in after normal businesshours, or from an alternate work location or travel destination. Forthese cases, the person's calendar would ordinarily indicate that theyare in an “unavailable” status of one type or another (that is, thecommuting, after hours, at alternate work location, or traveling statuswould not be recognized as “free time” in which meetings could bescheduled). As an example of results that are not sufficientlyconstrained when based solely on free time, it may happen that someinvitees need to be present at the meeting in person, in which case thelocation of the person is important (in terms of their ability to get tothe meeting location), not just whether there is free time on theperson's calendar.

The following scenarios illustrate various factors that are notaddressed by prior art calendaring systems or their schedulingcapabilities. (These calendaring systems and search capabilities arereferred to herein generally as “prior art systems”.)

Scenario 1: Prior art systems do not understand nuances related to thephysical location of the invitees. Suppose, for purposes ofillustration, that Joe works at the Research Triangle Park (“RTP”) siteof International Business Machines Corporation (“IBM”), where this RTPsite comprises many buildings, some of which are in close physicalproximity to each other but others of which are located several milesaway. Further suppose that Joe wants to schedule a one-hour, in-personmeeting with ten other people who are also located at the RTP site. Joemay use a prior art free-time search capability to search the electroniccalendars for the invitees to find one hour where all ten meetinginvitees are available. Assuming that all ten people have a commonone-hour period available, this time period is selected, andprogrammatically generated meeting invitations are sent electronicallyto each invitee. Upon receiving their invitation, several of theinvitees decline the invitation because they are located in buildingsfrom which travel time will be required to get to and from the meeting,and they have events already scheduled on either side of the new meetingwhich prevent their being able to arrive at the next meeting on time.Joe did not manually factor this consideration into the schedule forthis meeting, and the prior art free-time search does not have thiscapability. So, Joe must now find a different hour when everyone canmeet, and must also factor in the various travel times for those peoplewho he determines will have to travel. This is a time-consuming effortthat requires Joe to not only know the locations of every invitee beforeand after the proposed meeting and the time it takes to move betweenthese locations and the meeting location, but to also use a combinationof free-time search, manual calendar search, and contacting peopledirectly before he can find an appropriate time for the meeting.

There might be other criteria to consider as well, further complicatingthe scheduling process. For example, some individuals may have travelconstraints (such as “Betty participates in a car pool on Tuesdays andThursdays and therefore has no car”) which prevent them from being ableto travel to a meeting at another location.

Scenario 2: Prior art systems do not understand availability beyondsimple free time. Suppose now that Joe needs to schedule a one-hour“e-meeting” with Elaine. (An e-meeting may use technology such as LotusSametime® or Microsoft's NetMeeting®, which allow people to hold“face-to-face” conversations over the Internet from their computingdevice. “Sametime” is a registered trademark of Lotus DevelopmentCorporation, and “NetMeeting” is a registered trademark of MicrosoftCorporation.) Elaine has many events on her calendar, including anout-of-town business trip scheduled for the current week (with meetingsscheduled every afternoon), all-day workshops the next week, andvacation the following week. Therefore, when Joe uses a prior artfree-time search to search her calendar for one hour of free time, hefinds that Elaine won't be available for three weeks. Joe gives up usingthe automated scheduling system, and calls Elaine's secretary whoinforms him that Elaine is actually available any morning during herbusiness trip for a one-hour e-meeting. Joe could not determine this bysimply looking at Elaine's calendar, and the prior art free-time searchis not programmed with this capability.

Scenario 3: Prior art systems do not understand constraints ofparticular locations and/or policies that impact a person'savailability. Suppose that Joe needs to talk to Fred, who travels fromone customer site to another in a five-state region. Joe looks at Fred'scalendar, and decides to schedule a call during a time in which Fred isscheduled to drive from one customer location to another. What Joedoesn't understand from merely inspecting the entries on Fred's calendaris that Fred will be driving in a state that prohibits cell phone callswhile driving. Thus, Joe schedules the meeting, only to learn that ithas to be rescheduled. Using the prior art free-time search to find timeon Fred's calendar would have not helped in this situation: theautomated search would be impaired by the same missing information thatJoe needed when manually inspecting Fred's calendar.

In another aspect of this scenario, if the meeting is to discussconfidential topics and corporate policy prohibits discussingconfidential information over cell phones, then Joe would need tounderstand this and not schedule the call while Fred is driving (orduring other times when Fred is reachable only by cell phone).

Scenario 4: Prior art systems do not understand capabilities/limitationsof various technologies. In yet another aspect of the scenario describedabove, where Joe wants to reach Fred by cell phone, it might happen thatFred is traveling through a location that allows cell phone calls whiledriving, provided the cell phone is operated in a “hands-free” mode.Before he could successfully schedule a call with Fred, Joe would haveto understand not only where Fred would be at the selected time and anyapplicable constraints of that location, but also the capabilities ofFred's phone.

Scenario 5: As another example of technology-related constraints,suppose that Joe needs to set up an e-meeting with Barney. Furthersuppose that Barney is working from home today, according to hiscalendar. Joe has a high-speed connection in his office, and assumesthat everyone else has similar capabilities, so he decides to set up themeeting for today. Barney, however, has a low-speed connection at home.The e-meeting is a disaster, due to the slow line speed.

Scenario 6: Prior art systems do not understand nuances of blocked time,such as time periods marked as having a “local travel” status. Supposethat Joe is trying to schedule a meeting with Wilma at noon in Buildingnumber 500. Wilma is in this building from 11 a.m. to noon, according toher calendar, and then has “local travel” scheduled on her calendar fromnoon until 12:15, giving her time to drive back to her office which islocated several miles away in another building. The prior art free-timesearch would not show that Wilma is actually available at noon inBuilding number 500.

Accordingly, what is needed are improved scheduling/searchingtechniques, where these improved techniques consider factors beyondavailability of free-time segments on a user's calendar.

SUMMARY OF THE INVENTION

An object of the present invention is to provide improved techniques forperforming free-time searches of availability information.

Another object of the present invention is to provide these improvedtechniques by considering factors beyond availability of free-timesegments on a user's calendar.

Another object of the present invention is to provide improvedscheduling techniques.

It is a further object of the present invention to provide improvedtechniques for analyzing electronic calendar entries and associatedcalendar data.

Yet another object of the present invention is to make electroniccalendars more useful.

Still another object of the present invention is to define extensions toelectronic calendar systems that can be leveraged for improvedsearching.

Other objects and advantages of the present invention will be set forthin part in the description and in the drawings which follow and, inpart, will be obvious from the description or may be learned by practiceof the invention.

To achieve the foregoing objects, and in accordance with the purpose ofthe invention as broadly described herein, the present inventionprovides systems, methods, and computer program products for improvingfree-time searches and scheduling. In one aspect, this techniquecomprises: programmatically scheduling a meeting by evaluating, for eachinvitee of the meeting, calendar data of an electronic calendar todetermine each invitee's availability for attending the meeting in oneor more allowable participation types; and then scheduling the meetingat a time and location where the invitees are determined to be availablefor the allowable participation types. The evaluation may furthercomprise applying factors such as a particular invitee's user-specificpreferences and/or corporate policy considerations to determine whetherthe particular invitee is available for attending the meeting in one ormore allowable participation types for this particular invitee. Suchfactors may also be used to determine whether a particular meetinglocation is available for scheduling the meeting. Each meeting inviteemay have a plurality of allowable participation types, in which case thescheduling of the meeting preferably further comprises scheduling themeeting at a time and location where each invitee is determined to beavailable for at least one of his/her allowable participation types.

In another aspect, the techniques of the present invention compriseperforming a free-time search of calendar data by: retrievingavailability information for a plurality of users; locating free-timesegments which are available in the retrieved availability information;adjusting the located free-time segments based on one or morecontext-sensitive criteria which are applicable to this free-timesearch; determining one or more free-time segments when each of theplurality of users is available, according to the adjusted free-timesegments for each of the users; and providing the determined free-timesegments as a result of the free-time search. The retrieved availabilityinformation preferably comprises calendar data from the users'electronic calendars.

In yet another aspect, the techniques of the present invention compriseprogrammatically scheduling an event for a plurality of users by:retrieving availability information for a plurality of users; locatingfree-time segments which are available in the retrieved availabilityinformation; adjusting the located free-time segments based on one ormore context-sensitive criteria which are applicable to the event beingscheduled; determining one or more free-time segments when each of theplurality of users is available, according to the adjusted free-timesegments for each of the users; and providing the determined free-timesegments as candidate times for scheduling the event.

The context-sensitive criteria preferably comprise one or more of: userpreferences of one or more users; policy considerations; legalconstraints; location constraints; technology constraints; and deviceconstraints.

The adjusting process preferably further comprises: analyzing locatedfree-time segments in one or more busy bars for each of the users; andmarking a particular one of the analyzed free-time segments as abusy-time segment if the context-sensitive criteria indicate that thisuser is not actually available during this particular time segment. Theadjustments may be made for each user's retrieved availabilityinformation in view of one or more allowable participation types forthat user. If the participation type allowed for a particular user isin-person participation in the event, then marking free-time segments asbusy-time segments is performed if the context-sensitive criteriaindicate that the particular user is not available for in-personparticipation during the selected time segment. For in-personparticipation, travel time is computed as part of the process, and thetravel time between locations may be obtained in a number of ways.User-specific adjustments may optionally be applied to the computedtravel time. The travel time may represent more than one mode of travel.

In still another aspect, the techniques of the present inventioncomprise scheduling a meeting by: selecting one or more meetinginvitees; selecting, for each invitee, an allowable participation level;evaluating availability information for each invitee, with reference tothe allowable participation level; and using results of the evaluationfor all invitees to determine when the meeting can be scheduled. Theallowable participation level for each invitee may be a minimum requiredparticipation level, in which case the evaluation process evaluates theavailability information for each invitee for the minimum requiredparticipation level and for zero or more higher-ranking participationlevels which are implied by the minimum required participation level.Or, the selection may be of one or more explicitly-specifiedparticipation levels for each invitee, in which case the evaluationprocess evaluates the availability information for each invitee for eachof the one or more explicitly-specified participation levels of thatinvitee.

One or more candidate meeting times may be determined when all inviteesare available according to the evaluation process. A meeting locationsupplied by a meeting scheduler may be considered as a constraint onwhen the meeting can be scheduled. One or more meeting preferencessupplied by the meeting scheduler might additionally, or alternatively,be considered in determining when the meeting can be scheduled.

The results of the evaluation are preferably presented to a meetingscheduler, who may then select from among a plurality of potential timesand/or locations in the presented results. Meeting invitations may thenbe sent automatically to the invitees, wherein the meeting invitationsspecify the selected time and location. The meeting invitations mayfurther specify travel time to and/or from the selected location forthose invitees for whom in-person participation is an allowableparticipation level, and may specify one or more allowable participationlevels for each meeting invitee.

The present invention will now be described with reference to thefollowing drawings, in which like reference numbers denote the sameelement throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 provides a sample graphical user interface (“GUI”) display whichmay be used to enter scheduling criteria, according to the presentinvention;

FIG. 2 provides an overview flow chart which sets forth logic that maybe used when implementing preferred embodiments of the presentinvention;

FIGS. 3-7 illustrate flow charts which set forth logic that may be usedto implement free-time searches for scheduling a meeting in a particularlocation, according to preferred embodiments of the present invention;

FIG. 8 illustrates how a sample “busy bar” is programmatically adaptedby preferred embodiments of the present invention to account for traveltime;

FIGS. 9-11 provide flow charts which set forth logic that may be used todirect free-time searches in the absence of a pre-specified meetinglocation, according to preferred embodiments of the present invention;and

FIG. 12 illustrates a sample GUI showing results of a search wheremultiple potential meeting times and locations were found.

DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention defines improved techniques for finding commonfree time, where this common free time is described herein withreference to scheduling meetings among calendar owners using informationof the type used by electronic calendars. The disclosed techniquesprovide more intelligent searching of calendar data, resulting inimproved calendar-based scheduling; thus, the terms “searching” and“scheduling” may be used interchangeably when describing advantages ofthe present invention. (While the discussions herein presume that aperson's availability information comes from electronic calendar data,this is for purposes of illustration and not of limitation. The actualorigin of the availability data may be different, without deviating fromthe scope of the present invention. Furthermore, preferred embodimentsare described herein with reference to scheduling meetings. However, thedisclosed techniques may be adapted to other uses, including but notlimited to scheduling other types of events, and such other uses areconsidered within the scope of the present invention.)

The term “calendar data” is used herein to describe information of thetype used by electronic calendars, which preferably comprises calendarentries as well as other information such as the calendar owner'sworking hours, the time zone for a particular calendar, and preferencesthat, for example, could indicate how a calendar owner's calendarentries should be interpreted and/or could provide schedules for whendevices such as cell phones or pagers could be used.

The present invention defines techniques whereby the search for freetime overcomes limitations of the prior art. In preferred embodiments,an implementation of the present invention is adapted for understanding(i.e., for programmatically analyzing) not only calendar data but alsonuances related to the physical location of the invitees; availabilitybeyond simple free time; constraints of particular locations and/orpolicies/laws/regulations that impact a person's availability;capabilities/limitations of various technologies that impact a person'savailability; and nuances of blocked time. Preferred embodiments alsoaccount for individual preferences and user-specific constraints, aswill be described in more detail herein. Relationships among physicallocations, such as distances between various locations and travel timefrom one location to another, are factored into the scheduling processin preferred embodiments. Using these various types of information,referred to herein as “contextual” information or “context-sensitiveinformation”, embodiments of the present invention intelligently findfree time that meets real-world scheduling considerations.

Alternative embodiments may omit consideration of policies, laws,regulations, and/or technology-based constraints without deviating fromthe scope of the present invention.

Prior to performing a context-sensitive free-time search using animplementation of the present invention, several different types ofinformation that will be leveraged in the searching process need to beset up and available. In preferred embodiments, the following componentsmust be available: (1) a location database; (2) a means of estimatingtravel time; (3) a policy database; (4) a user preferences database; (5)information of the type used by an advanced calendaring system; and (6)means for determining the location of scheduled calendar events.(Alternative embodiments may omit one or more of these databases, andadditional databases with other constraints could be included in thesearch considerations.) While the discussion herein refers toinformation residing in separate databases, it may be stored in fewerdatabases or may be stored in other repositories (such as a set oftables). Furthermore, while preferred embodiments are described withreference to use of databases, this is merely for illustrative purposes:services (including one or more commercially-available services) mightbe invoked for retrieving one or more of these types of information; inaddition, the information may be in a more sophisticated form than whatis described herein. As an example, rather than retrievingstatically-stored travel time from a database or computing a travel timeestimate based on the geographical distance between two points, animplementation of the present invention might alternatively contact atravel time service that dynamically computes travel time and which mayalso incorporate additional factors such as the impact of rush-hourtraffic (where such a service is adapted for determining the appropriaterush-hour information, such as times of day and locations for which rushhour is a concern, the amount of delay to add, and so forth). Each ofthe above-mentioned components will now be described in more detail.

A location database comprising information about sites (and/orlocations) is preferably created by the enterprise hosting the free-timesearch service. A “site”, as the term is used herein, refers to a set oflocations that a person may commonly and easily commute between. Forexample, the term “the RTP site” is used herein to signify a collectionof buildings located in Research Triangle Park, North Carolina. Thelocation database may be organized (e.g., subdivided) according to thelocations comprising the physical site. In the general case, thelocations within a site could include office buildings and/or other workareas (such as construction areas, airports, hotels, and restaurants).An enterprise may have numerous sites, in which case the locationdatabase is preferably organized according to site within enterprise andlocation within site; or, separate location databases might be used foreach site. Typically, a systems administrator will create and populatethe location database.

Information stored in the location database for each location preferablyincludes the physical coordinates of the location (such as the latitudeand longitude where a building is located), which may be used to computedistances between locations, and/or a set of tuples specifying thedistance or travel time between each pair of locations in the database.

The location database preferably includes a listing of meeting rooms(which may include individual office locations), conference rooms, videoconference rooms, or other types of facilities (where these terms areused interchangeably herein) in each building/location, and may alsoinclude location-specific facility-related constraints. Examples ofthese constraints include the number of people each meeting room canaccommodate, whether (and, optionally, in what ways) the meeting roommeets requirements of the physically challenged, technology constraintssuch as the speed of a network connection that is available from themeeting room, device availability in this meeting room, whether thismeeting room is acceptable for discussing the meeting subject matter,and so forth. (While meetings are described herein primarily in terms ofbeing held in an enterprise's on-site facilities, this is merely forpurposes of illustration. Other locations such as public restaurants orconference centers might be used alternatively. As an example oflocation-related constraints that may apply to a particular location,the discussion of confidential information may be prohibited in arestaurant or other public location.)

A means of estimating travel time is leveraged for determining whetherpersons who must attend a meeting in person will have sufficient time toget to the meeting and/or to get to a meeting which follows the meetingbeing scheduled. One example of how travel time estimates may beprovided is to create a set of tuples which statically specifies theestimated travel time between each pair of locations in the locationdatabase, as mentioned earlier. Optionally, the preferred travel meansbetween locations may also be included. For example, walking might beindicated as the preferred travel means between two relatively closebuildings, whereas car travel might be indicated for longer distances orfor routes which are unsafe for pedestrians. Another example of howtravel time estimates may be provided is to base the estimated time onthe location-to-location distance tuples in the location database.Alternatively, the estimate of travel time could be derived, forexample, from a mapping service such as those which are commerciallyavailable for generating driving directions from one address/location toanother.

In addition to building-to-building travel time estimates, within alarge physical space such as a large office building, internal traveltime (such as an estimated walking time) could also be estimated betweenoffices based on the distance between the offices.

Embodiments of the present invention are preferably adapted forcomputing the complete travel time that will be required for aparticular person to get to a meeting. For example, rather thancomputing only driving time between two places, factors such as thelength of time that will be required for the person to park her car in aparking lot, then walk to the building in which the meeting is beingheld, and then walk to the meeting room (and/or, as appropriate for aparticular meeting, the time to perform such activities upon leaving themeeting) are also preferably included in the travel time estimates. Inlarge physical spaces, these additional activities may add aconsiderable amount of time to the overall travel estimate. It mayhappen that some people may require more time for these types ofactivities than other people require. Preferably, user preferences(described below) are used to specify how travel time estimates shouldbe adjusted on a per-user basis.

The discussions herein assume that a person is willing and able, unlessotherwise indicated in his/her preference settings, to travel betweenlocations within a site. With additional preference settings and theaddition of site-to-site travel time information, which could be acombination of static data and derived data (derived, for example, fromairline or train schedules, and preferably also consideringtravel-related factors such as the time required to park and betransported from the parking lot, the time required to check in for thetrip, the time spent retrieving luggage upon arrival, and so forth), thetravel time considerations may be extended to include site-to-sitetravel.

A policy database may be set up by the enterprise hosting the improvedfree-time search service disclosed herein. This policy database mightcontain policy statements such as:

-   -   Do not hold business meetings in employee homes.    -   Do not take part in a confidential meeting via cell phone.    -   Do not use a cell phone while driving.    -   Do not take part in confidential meetings in public locations.

As briefly discussed earlier, legal (or regulatory) considerations mayalso affect a person's availability for meeting participation. Thus, thepolicy database (or a separate database) could provide legalconstraints, such as whether cell phone conversations are allowed whiledriving. Legal considerations may optionally be associated with fixedgeographic boundaries.

A database is preferably provided to record user preferences oruser-specific constraints/policies. (The term “user preferences” shouldbe construed as referring also to user-specific constraints andpolicies, such as “Betty can't travel to meetings on the days she ridesin the car pool”.) For a particular user, these preferences could bespecified using the calendar application or by another means. In thisuser preferences database, the user may be allowed to define additionallocations, such as his home or office, and may define preferences andconstraints for those locations. For example, Fred may define his officeas a meeting location, and may specify constraints such as how manypeople can be accommodated for meetings in this office, etc.

Optionally, technology-related information such as device availabilityor connectivity information may be specified for each user-addedlocation (as well as for the user's normal work location). For example,Joe might specify that he has a high-speed connection when he is at hisprimary home, but only a low-speed connection while at his beachcondominium and that he will not have any network connectivity at allwhen his scheduled calendar event is “on vacation”. Travel time from auser-added location to one or more of the locations defined in thelocation database may be statically specified, or travel time may beestimated using one (or more) of the techniques described above whendiscussing means of estimating travel time.

In addition, the user could specify personal preferences such as:

-   -   I prefer afternoon meetings.    -   If I have to travel between locations, I prefer having the        meeting at the beginning (or the end) of the day.    -   All meetings have to be in my office complex, i.e., locations I        can walk to (for a person without a car or other means of        transportation).    -   If working at home, I am not available for in-person meetings.    -   Add 10 minutes to all corporate-provided travel time estimates.

User preferences may also be used to specify device-related informationfor this invitee, such as the fact that Wilma's cell phone allowshands-free operation. (This may be significant, for example, where locallaw or corporate policy forbids use of cell phones while driving unlessthe phone can be operated in hands-free mode.) Alternatively, this typeof device-specific information might be stored in a differentrepository. For example, Wilma might have preferences informationspecific to her car or other location, where this type of device-relatedinformation may be stored.

Information of the type used in an advanced calendaring system isrequired, where this information can be used to derive a schedule ofwhen a person is available via different means such as in person, bytelephone, or using some other communication means. Embodiments of thistype of advanced calendaring system are disclosed in the aforementionedrelated U.S. Patents. U.S. Pat. No. 6,988,128 (Ser. No. 09/670,844)discloses techniques for analyzing information in calendar entries(along with optional preference data) when an incoming event occurs(such as an incoming e-mail message or voice message, or a request forproject management status information). The analysis determinesavailability (and/or other information) of the calendar owner, andprogrammatically generates a response to the incoming event. Forexample, if an e-mail message arrives while the recipient's calendarindicates that she is on vacation, a message can be returned immediatelyto notify the sender that the message recipient is away (and willtherefore not be sending a quick personal response). U.S. Pat. No.6,640,230 (Ser. No. 09/671,001) teaches preprocessing calendar events,creating a table or other repository having entries which represent acalendar owner's distinct types of status within a particular timeperiod. Upon receiving an incoming event, this stored data can beinspected to determine an appropriate programmatic response. Acombination of on-demand (i.e., event-driven) generation andpreprocessing may also be used (for example, to verify thatpreviously-generated information is still current).

U.S. Pat. No. 7,035,865 (Ser. No. 09/941,045) discloses enhancements toan advanced calendaring system whereby instant messaging systems andelectronic status boards are preemptively notified of status changes fora defined set of users, and whereby recipients of status information canrequest retransmission and optionally acknowledge receipt thereof U.S.Pat. No. 7,096,232 (Ser. No. 09/875,556) discloses techniques wherebycalendar data can be analyzed to discern availability of a person orgroup of people for various types of contact (for example, when they arenext available by phone, e-mail, in person, and so forth).

Enhancements to the data described in the related inventions are needed,whereby clearly-defined (i.e., machine-processable) physical locationinformation or a reference thereto is stored with (or otherwiseassociated with) individual calendar events. A calendar user interfaceis preferably provided to allow a calendar owner to specify thislocation information on his/her calendar entries. This could befree-form text (similar to the free form text allowed in prior artcalendar entries). As another approach, the user could be provided withoptions such as using a pulldown list of known sites for the hostingenterprise, a selection from which would then tailor a second pulldownhaving choices of the known locations at that site. As still anotherapproach, a single-level pulldown menu might be used, or the user mighttype in physical address information (such as latitude and longitudevalues, the nearest intersection or cross streets, the location's streetaddress, etc.). Optionally, filtering may be applied before displayingchoices in a pulldown menu, such that only locations that are acceptableaccording to constraints of each particular calendared event areprovided. (For example, if a meeting is scheduled and the meetinglocation must be wheelchair-accessible, then any meeting facilities notmeeting this requirement may be omitted from the display by using afiltering operation.)

Given the above information, a user can perform a context-sensitivefree-time search using multi-dimensional search criteria, as describedin detail herein, corresponding generally to the type of detailedinstructions that a person might give to an administrative assistant forperforming a labor-intensive manual scheduling process of the prior art.The multi-dimensional, context-sensitive search supported by embodimentsof the present invention is in contrast to current state-of-the-artmeeting scheduling systems, which allow the user to enter the names ofthe participants and possibly a suggested meeting time (and, in someprior art systems, whether a meeting room needs to be reserved). Themanner in which preferred embodiments operate will now be described.

When a user of the present invention requests a search for findingavailable free time, preferred embodiments allow specifying a pluralityof meeting scheduling criteria. FIG. 1 shows a sample GUI display 100that may be used to enter an optional meeting subject 105 and one ormore of these scheduling criteria. The meeting duration is specified (asshown at 110), along with date and time constraints (see element 115).The date and time may be specified as an exact meeting date/time,however the user preferably specifies a range of dates and/or timeswithin which the meeting must be scheduled (thereby allowing greaterflexibility in scheduling).

Check boxes are preferably provided where one or more meeting-specificcriteria may be specified. As described earlier, corporate policies mayplace constraints on meetings having sensitive subject matter, such aswhether participation by cell phone is acceptable. As another example ofcorporate policy constraints, travel might not be authorized for certaintypes of meetings. Thus, the sample display 100 allows the personsetting up the meeting to indicate whether the subject matter isconfidential (see element 120). Additional/different types of policyinformation may be significant to a particular enterprise as well. Forexample, an enterprise's policy might state that meetings on certaintopics cannot be held unless all invitees are available, and a check boxmay be provided to set this constraint on or off.

Availability of audio/visual equipment is an example of facility-relatedconstraints a user might specify when scheduling a meeting. Acorresponding check box has therefore been provided in the sampledisplay at 125. Additional examples of facility-related meetingconstraints which are specified by the meeting scheduler include whetherthe selected facility must be wheelchair accessible (see element 130) orwhether it must provide support for hearing-impaired participants (seeelement 135). (In cases where the user has pre-selected the meetingfacility, then these facility-related constraints are typically notuseful. However, if the user does not specify a particular meetinglocation and instead requests that the search process also locates asuitable location for the meeting, as will be described in more detailbelow, then these constraints are preferably compared against thecandidate locations during the search process.)

Preferred embodiments of the present invention are adapted fordynamically determining user-specific information that constrains theselection of meeting facilities. Thus, even though the person schedulingthe meeting may be unaware of physical limitations of the invitees (andtherefore may not use the check boxes shown in FIG. 1), this informationwill be available for use during the search process. In preferredembodiments, user preferences are consulted for determining anindividual's particular constraints on meeting facility selection. Itmay also happen that a corporate database contains information aboutphysical limitations of the corporation's employees; in this case,individual constraints may also or alternatively be obtained from such adatabase.

When the person scheduling the meeting wishes to constrain the searchprocess to a specific location, a location entry field 140 is preferablyused. In this example, the user has selected “Specific Location” and thedisplay shows that a two-level menu approach is provided to specify thelocation, where the first level offers site choices of “Dallas”, “NewYork”, and “RTP”, and “RTP” has been selected. See element 145. Havingselected the RTP site, a second level of choices are provided, and mayoptionally be used to constrain the search to locations within thatsite. In the example, the second-level choices represent particularbuildings, denoted as “Bldg 5”, “Bldg 252”, and “Bldg 500”, and the“Bldg 500” choice is shown as being selected. See element 150. Anoptional filtering operation may be applied, as described above, suchthat the choices presented on the menus represent choices which meet theconstraints that have been provided. As stated above, selecting aspecific meeting location is optional, and the search process may beused to suggest potential locations. This is selected using one of theother two options for box 140: Select Location First or Search AllPossible Locations. (As will be obvious, in a multi-site implementationwhere sites are geographically dispersed, performance will be improvedby selection of a particular site. Thus, the user might be allowed toselect the RTP site in the first level menu but omit choosing aparticular building in the second level. Furthermore, an implementationof the present invention may support more than two levels in the menus.For example, an additional level might be added to account for a complexor group of buildings.)

It should also be noted that when in-person participation is notrequired, such as when invitees will participate by telephone (e.g., ina conference call), it is not strictly necessary to identify a location.Thus, an implementation of the present invention may be adapted forsuppressing entry of the location information based upon the requiredparticipation levels for this meeting (which are described below withreference to element 160). Or, if location information has already beenentered, an implementation may be adapted for ignoring the specifiedlocation if the meeting will be scheduled without the inviteesphysically present. (Ignoring the location in such cases may be done toimprove performance of the actual search process.)

The meeting invitees/participants are identified, as shown at 155. Aname or other identifier is entered that allows the searching process tofind the calendar data for that invitee. While the sample display showsindividual people's names, a facility might be supported for identifyinggroups of people (such as by entering a department name or number).Optionally, the calendar data to be used in the search may be data fromgroup calendars, in addition to or instead of data from individualcalendars.

Optionally, an implementation of the present invention may allow themeeting scheduler to identify a list of people whose participation inthe meeting is optional. Preferably, the calendar data for theseoptional participants is not used when searching for acceptable meetingtimes and locations. However, that calendar data is preferably used whendisplaying results of the search (to allow the meeting scheduler todetermine how these optional participants will be affected by selectinga certain time or location for the meeting, for example). FIG. 12,described below, is an example of how search results may be displayed.

The minimum participation level for the meeting invitees is alsospecified by the person scheduling the meeting. The sample display 100illustrates a capability for specifying different participation levelrequirements for each person included in the search. See element 160.(Alternatively, an implementation of the present invention might supporta single minimum participation level for all meeting invitees. This hasnot been illustrated.) According to preferred embodiments, participationlevels are defined as a sequentially-ordered list or ranking. “Inperson” participation, which imposes a requirement for the invitee'sphysical presence at the meeting, is defined as the strictest orhighest-ranking requirement. Selecting a minimum required participationlevel then implies that any higher-ranking type of participation is alsoallowable. A suggested participation level ranking which is used inillustrating operation of preferred embodiments is as follows, beginningwith the strictest requirement:

-   -   in person participation    -   participation by video conference    -   participation by e-meeting    -   participation by fixed telephone, high-speed Internet connection        available    -   participation by fixed telephone, low-speed Internet connection        available    -   participation by fixed telephone    -   participation by cell phone    -   “as needed” participation (i.e., the person would not        necessarily attend, but would be available on an as-needed        basis)    -   optional participation.

The “as needed” participation level may be useful for people whoseparticipation in the meeting is not necessarily required, but who mightneed to be called in for brief consultation or perhaps be available forsome other type of “exception basis” participation. This participationlevel is preferably used for communication methods where the user can becontacted from the meeting (e.g., by pager, instant messaging, telephoneor cell phone call, etc.) and can respond to the contact request. Theresponse might be by return page, instant messaging chat, return phonecall, or perhaps even by physically attending the meeting. The responseis not required to use the same communication means as the contactrequest. (Use of a one-way pager for receiving the contact notificationmay be acceptable in cases where other means will suffice forresponding.)

So, for example, if the minimum required participation level for Mary isspecified as “As Needed”, as shown at 170, this signifies (according topreferred embodiments) that this participation level and any otherparticipation level higher in the ranking are acceptable to the personwho schedules the meeting. Sally must be able to attend the meetingeither in person, by video conference if not in person, or by e-meetingif not in person or by video conference, or at least with a telephoneand high-speed connectivity available. See element 165. Note that as thestrictness of the participation level requirement decreases, thelikelihood of the invitees being able to participate in the meeting canbe expected to increase.

The list of choices shown at element 175 represents the suggestedparticipation level ranking discussed earlier. Note that this list ofchoices is merely illustrative. Additional, fewer, or different choicesmay be offered alternatively.

It should also be noted that this in-order participation level rankingis merely one manner in which various types of required/desired userparticipation may be specified. Alternatively, it might be preferable ina particular implementation of the present invention to require eachinvitee's participation level to be matched exactly as specified (suchthat if participation by telephone is specified by the meetingscheduler, for example, then an invitee is considered unavailable if hecannot participate by telephone). Other techniques may be suggested toone of skill in the art, once the teachings of the present invention areknown, and these alternative approaches may be used without deviatingfrom the scope of the present invention.

Turning now to a discussion of performing the context-sensitivefree-time search, preferred embodiments provide several options foridentifying the meeting location. First, the user who is scheduling themeeting may specify a particular meeting location. Or, the user mayprovide parameters with which a “good” or “preferred” location isprogrammatically selected/recommended by an implementation of thepresent invention. As another option, the location may be leftunspecified to maximize the search flexibility. (It should be noted,however, that performance may degrade when the location is leftunspecified in environments having many meeting invitees, manylocations, and/or many possible participation levels, due to the largernumber of potential matches that will be evaluated during the search.)Refer to the discussion of Block 930 of FIG. 9, below, for moreinformation on factors that may be used to select a “good” location.

The flowchart in FIG. 2 provides a high-level overview of how preferredembodiments of the present invention operate. The process starts atBlock 200, and proceeds to Block 210 where the user's search criteria(entered using a technique such as that described with reference toFIG. 1) are obtained. As stated earlier, these requirements may comprisethe list of invitees (referred to equivalently herein as participants),one or more participation levels, the meeting duration, a target meetingtime frame, optionally a location, and various other types ofinformation such as those which have been described earlier. At Block220, a test is made to see if the user performing the search hasspecified where he wants the meeting to be held (using, in the exampledepicted herein, selection boxes 140, 145, and 150 of FIG. 1). If not,processing continues at Block 230, which represents performing thesearch when a location is not specified. FIGS. 9-11 provide details onhow this operates in preferred embodiments. (Note that preferredembodiments of this processing invoke the location-driven search ofFIGS. 3-7. See Blocks 940 of FIG. 9 and 1030 of FIG. 10.)

When the user specified a search location, the test in Block 220 has apositive result, and control transfers to Block 240 where acontext-sensitive search having a specific target location is performed.FIGS. 3-7 provide details on how this search proceeds in preferredembodiments.

Following completion of Blocks 230 or 240, processing reaches Block 250where the computed search results are presented to the user for hisreview. A sample search results display is provided in FIG. 12, and willbe described below. After the user's review, he may decide to re-do thesearch (i.e., perform it again, perhaps with different invitees and/ordifferent constraints), to quit, or to accept a generated result andsend out meeting invitations to the invitee list.

If the user selects to re-do the search, then control returns to Block220 to start again. If he selects to exit, then the processing of FIG. 2ends. If he selects to accept a result of this search, control reachesBlock 270. It may happen in some cases that the generated resultscontain a number of possible dates, times, and/or locations for themeeting. In these cases, before sending the invitations, the user needsto select from among the choices, as indicated in Block 270. Aftermaking a selection, the invitations are sent (Block 280), and thisiteration of the search process then exits.

Prior art calendaring systems perform automated invitation-listmailings, whereby meeting invitations are sent electronically to aparticipant list. However, the intelligent free-time search of thepresent invention provides advantages over these prior art systems(which do not account for travel time and which are not adapted forhandling a variety of participation levels or other types ofconstraints). Preferably, the invitations generated at Block 280 includea user-specific designation of the minimum type of participationexpected. And, since the search process as disclosed herein knows thetravel time between locations for each in-person participant,user-specific travel time information is preferably included in thegenerated invitations. In preferred embodiments, the travel time ishandled by sending up to three invitations: one for the meeting, and ifrequired, one for the travel time before the meeting and/or one for thetravel time after the meeting. In alternative embodiments, a singlemeeting invitation is sent in Block 280, and includes the user-specifictravel times which were determined. The recipient may then manage thosetravel times manually.

Referring now to FIGS. 3-7, flow charts will be described which may beused to implement free-time searches for scheduling a meeting in aparticular location. Conceptually, the context-sensitive free-timesearch may be viewed as follows:

-   -   A person's availability for a day can be represented by a set of        “busy bars” on a time-line representing the day, where time        segments are blocked out on the time-line to represent the        events which are scheduled on the calendar owner's schedule.        These blocked out time segments are busy (i.e, unavailable)        time, and the other time segments are free time. Busy bars will        be described in more detail with reference to the illustrations        in FIGS. 8 and 12, below.    -   A person may have multiple busy bars, each representing a type        of participation being evaluated by the search process. For        example, suppose that cell phone participation is being        evaluated. If Betty is available continuously between 9 a.m. and        6 p.m. by cell phone, then she will have a cell phone busy bar        with the time segments from (1) midnight to 9 a.m. and (2) 6        p.m. to midnight both marked as “busy”, while the time segment        between 9 a.m. and 6 p.m. is marked as “free”. Similarly, if        Betty is available for in-person meetings only between 10 a.m.        and noon, then her in-person busy bar will have the day broken        up into the three segments demarcated by 10 a.m. and noon.    -   The context-sensitive free-time search then proceeds by        evaluating the busy bars for each invitee which correspond to        that invitee's allowable participation levels, based on the        participation levels specified by the person conducting the        search.    -   The free/busy times on the busy bars are then adjusted as        necessary to take into account the extra considerations (i.e.,        travel time when evaluating in-person participation, corporate        policy, and/or user preferences) which are supported by an        implementation of the present invention.    -   The free-time search then proceeds to analyze the busy bars,        looking for free-time segments sufficiently long to schedule the        meeting to allow participation by all invitees.

The location-specific searching process illustrated by FIGS. 3-7 beginsat Block 300, and passes control to Block 310 where one of the inviteeswhich has not yet been processed is selected. (Each of the invitees willbe processed in turn, one at a time, by looping back to Block 310 fromBlock 720 of FIG. 7.) Block 320 obtains information from the calendaringsystem that shows this person's status for various types ofavailability. Preferably, all calendar data (including working hours,etc.) for this user is retrieved. User preferences are then consulted todetermine this user's individual status during each event. (For example,a particular user might define a preference that indicates “during eventtype X, I am available by cell phone”; another preference that indicates“during event type Z, I am not available”; and so forth.) Theavailability information therefore represents availability in person,via telephone, via cell phone or pager, the user's instant messagingstatus, and so forth. Refer to the aforementioned related inventions fora detailed description of how this information may be stored in, andretrieved from, the advanced calendaring system disclosed therein.(Generally, the techniques disclosed in the related inventions enable auser access to programmatically derived data that is analogous to thatwhich could be derived manually by a person looking at a calendar todetermine if someone is available at a certain time and then manuallyinterpreting the calendar in view of other information of the type thatwould be given to an administrative assistant. For example, beforeleaving for a business trip to Europe, Betty might tell her secretary “Iwon't be taking my cell phone, so even though I am normally reachable bycell phone while I'm traveling, that does not apply for this particulartrip.” By augmenting calendar data as disclosed in the relatedinventions, and leveraging a system of preferences, the advancedcalendaring system disclosed therein knows the various means by which aparticular user is available.)

After completing Block 320, the search process knows, for each timesegment, whether there is a free event or a busy event on this invitee'scalendar. Furthermore, when the events include location information, asdiscussed earlier, the search process knows where this meeting inviteeis scheduled to be during each time segment. For those types ofparticipation which have no other constraints (such as “available bytelephone” participation), no further analysis is done at this point.For those participation types which include technology requirements,such as “telephone plus low-speed connection” participation, the userpreferences database and/or location database (either of which maycontain information such as the speed of connectivity from a particularlocation) are consulted (Block 330) to determine whether that technologyrequirement is met for this invitee during the time segment of interest.In this manner, each invitee's availability can be determined, for anyof the types of communication mechanisms. So, for instance, if this useris available by telephone and will have access to a low-speedconnection, then a busy bar for this person will contain free and busyblocks to represent when the user is available for participation in thismanner.

This user's availability can then be displayed graphically by atime-line with a set of busy bars, where those bars represent the user'sfree/busy times. (Prior art calendaring systems that perform free-timesearches typically represent search results using a busy bar withfree/busy-time segments. However, they do not provide busy bars perparticipation level.) Block 340 takes the data from Blocks 320 and 330and creates a set of these busy bars for this meeting invitee, whereeach busy bar in the set represents one of the ways in whichparticipation is allowed for this meeting. Along with this free/busyinformation, preferred embodiments maintain some of the pertinentunderlying calendar information (in particular, the location value andevent type associated with the calendared events) as it will be neededlater as these free/busy-time segments are altered (see Blocks 440 and460 of FIG. 4).

Upon completion of Block 340, processing continues at Block 400 of FIG.4, where each of the participation types (and corresponding busy bars)will be evaluated. (Control returns to Block 400 from Block 700 of FIG.7, while iterating through the participation types for this meetinginvitee). Block 400 selects one of the remaining participation typeswhich has not been analyzed for this invitee.

The test in Block 410 checks to see if this busy bar represents anallowable participation type for this person at this particular meeting.For example, this busy bar might correspond to “as needed” availability,when this invitee is required to be present by telephone. Thus,according to the participation level ranking, participation in the “asneeded” mode is not allowed for this invitee, and the test in Block 410will have a negative result. In cases such as this, this busy bar willbe marked as completely busy (Block 420), since it cannot be used.

Note that the “all-busy” processing of Blocks 410 and 420 is anoptimization used in preferred embodiments to improve the search processby not searching time segments for disallowed participation types.(Alternatively, this optimization may be omitted without deviating fromthe concepts disclosed herein.) This all-busy status applies only forpurposes of searching the busy bars; the calendar entries are notactually changed. Alternatively, the busy bars for disallowedparticipation types can be processed but then ignored during the search.If it is desirable to show the invitee's availability to the meetingscheduler when the results of the search are presented (as shown in thesample results in FIG. 12), then this invitee's availability status forthis participation type may be processed (e.g., using the processdepicted in FIGS. 5 and 6 to account for corporate policy and userpreferences) and displayed to the meeting scheduler. It will be obviousto one of ordinary skill in the art how the flowcharts can be adaptedfor this purpose. (For example, the processing of Blocks 410 and 420 maybe deleted, such that actual availability for the disallowedparticipation types is computed by performing the logic of FIGS. 5 and6, and then omitting the busy bars for the disallowed participationtypes when performing the search.)

After performing the optimization in Block 420, control then transfersto Block 700 of FIG. 7, which will continue the iteration through thisinvitee's busy bars until reaching the end.

On the other hand, suppose that this busy bar represents “telephone pluslow-speed connectivity”, when the invitee's required participation levelis “telephone” availability. In this case, the busy bar for telephoneand low-speed connectivity represents an allowed participation type.Thus, control will transfer to Block 430. A test is made at Block 430 tosee if the current participation type being evaluated is in-personparticipation. If so, then preferred embodiments of the presentinvention programmatically factor this invitee's user-specific traveltime and constraints into his/her availability by performing the logicof Blocks 440-460. (If the participation type being evaluated is notin-person participation, then travel time is not pertinent and inpreferred embodiments is not computed; instead, processing continues atBlock 500 of FIG. 5 to begin evaluation of additional schedulingconstraints.)

Thus, when the in-person busy bar is being processed, control reachesBlock 440 which begins the process of adjusting time segments on thein-person busy bar to reflect travel time to and from the meeting beingscheduled. Block 440 deletes, from this busy bar, all the blocked (i.e.,“busy”) time segments that represent travel time. This is because traveltime may increase or decrease, depending on when/where the meeting underevaluation is scheduled.

Block 450 then determines, for each busy-time segment on the busy bar,how long it would take the invitee to travel from the location of thatevent (i.e., the event which causes a time segment on the bar to bemarked as busy) to the location of the meeting under evaluation.Similarly, travel time is preferably computed for leaving the meetingunder evaluation and traveling to the invitee's next scheduled event. Ifthe travel time between locations cannot be determined during operationof Block 450, then preferred embodiments preferably use anadministrator-assigned default travel time. (Or, alternatively, animplementation may be written to prompt the user who is scheduling themeeting to provide an estimate of the travel time between theselocations.) In preferred embodiments, user preferences are applied tothe travel time estimates to yield this meeting invitee's individualtravel time. (As an example of a user-specific travel time preference,Barney might specify that 10 minutes should be added to all travel timeswhere driving is involved, because he likes to park at the far end ofthe parking lot.)

Block 460 then extends the time of each busy-time segment on the busybar, in both directions (as applicable, depending on whether travel isrequired for the neighboring time segments), by the length of the traveltimes computed in Block 450. (Note that different travel times might becomputed for traveling to the meeting and for traveling from themeeting.) Now, as a result of the processing of Blocks 440-460, any freetime remaining on the busy bar is available for scheduling the newmeeting, and the person will have time to get to and from that meeting.

An example of operation of Blocks 440-460 will now be illustrated byreference to FIG. 8, showing how a busy bar is programmatically adaptedin preferred embodiments to account for travel time. The original busybar 800 shows that the user is in Bldg. 500 from 8 a.m. to 10 a.m., thentravels for 30 minutes and arrives at Bldg. 656 at 10:30. Suppose thisuser's office is located in Bldg. 656, and that she had been in Bldg.500 for a meeting. Now, the user remains in Bldg. 656 until 2 p.m., andis then scheduled to travel for one hour to Bldg. 659 for anothermeeting or other event. She is therefore scheduled to arrive at Bldg.659 at 3 p.m., and to leave at 5 p.m. The chart at 820 shows an exampleof the user's travel path from Bldg. 500, then to Bldg. 656, and then toBldg. 659. (Chart 820 is provided merely for purposes of illustration;this chart is not a requirement of the present invention.) Now supposethat this user's calendar is being evaluated to see if she canparticipate, in person, at a meeting in Bldg. 002. Because her normalwork hours are from 8 a.m. to 5 p.m., it appears by evaluating the busybar 800 (which has been constructed according to the prior art, and hasalready blocked out travel time for the two meetings) that the onlypossible time for scheduling the meeting with this user's participationwill be between 10:30 a.m. and 2 p.m. However, the scheduling process ofthe present invention understands that some of the blocked-out timebetween 10 a.m. and 10:30 a.m., and between 2 p.m. and 3 p.m., mayactually be available for a new meeting.

The chart at 840 illustrates how the user's travel path may change ifshe is scheduled to attend a meeting in Bldg. 002, where she will travelfrom Bldg. 500, then to Bldg. 002, and then to Bldg. 659. (If themeeting in Bldg. 002 plus its travel time requirements do not fill theentire mid-day space, then the user might actually return to Bldg. 656before and/or after Bldg. 002, but that is not pertinent to the presentillustration.) Chart 840 shows that the user may actually require lesstime for traveling if this extra meeting is scheduled, due to itslocation.

Thus, the travel time entries on busy bar 800 will be deleted byoperation of Block 440, creating the busy bar shown at 860. Now supposethat instead of 30 minutes and one hour for travel, as on the originalbusy bar 800, information available to the scheduling system in Block450 indicates that travel time from Bldg. 500 to Bldg. 002 is 15minutes, and travel time from Bldg. 002 to Bldg. 659 is 45 minutes.These new travel times are placed on the in-person busy bar 860 by Block460, creating the adjusted busy bar 880. Therefore, this user canparticipate in (and arrive on time for) the meeting in Bldg. 002 if itis scheduled to start no sooner than 10:15 a.m., as shown in the revisedbusy bar at 880. Similarly, she can arrive on time for her 3 p.m.meeting in Bldg. 659 so long as her meeting in Bldg. 002 gets over atleast by 2:15 p.m., allowing her 45 minutes to travel to Bldg. 659.There is therefore a 4-hour window in which this user is available forparticipating in-person at a mid-day meeting in Bldg. 002 (and not a3½-hour window, as would have been indicated by the prior art busy bar800).

Returning now to the discussion of the flowcharts, having thus adjustedthe in-person busy bar in Block 460, processing continues at Block 500of FIG. 5.

The logic in FIG. 5 applies corporate policy considerations to thefree-time search to see if, according to corporate policy, the user'sfree-time segments really are available for this meeting. For example,if the busy bar represents cell phone availability and the meeting isconfidential, and if the corporate policy is that cell phones are not tobe used for confidential meetings, the processing of FIG. 5 would resultin the busy bar for cell phone availability being marked as totally busy(i.e., never available for this meeting).

The test in Block 500 checks to see if there are any free-time segmentsin this busy bar. If not, then control transfers to Block 600 of FIG. 6to begin applying user-specific preferences and considerations.Otherwise, processing continues at Block 510, which checks to see ifthis type of participation is allowable, according to policyconsiderations. (As stated above, if the participation type is via cellphone and the meeting scheduler has indicated that confidential topicswill be discussed, then the corporate policy might prohibit use of thistype of participation.) If not, then control transfers to Block 560,which sets all time segments on this busy bar to “busy” (i.e.,unavailable for scheduling); control then transfers to Block 600 of FIG.6. Note that Blocks 510 and 560 are an optional optimization that maymark the entire busy bar as “all-busy”, based on corporate policy, as analternative to repeatedly looping through each time segment. Thisoptimization may be omitted without deviating from the conceptsdisclosed herein.

When this participation type is allowable according to policyconsiderations, control transfers from Block 510 to Block 520 where afree-time segment that has not yet been processed by the logic of FIG. 5is selected. Block 530 checks to see if this time segment conforms tocorporate policies, and if not, then Block 540 marks the segment asbusy. For example, using the previously-described example, suppose thetime segments on the busy bar for cell phone participation are beingprocessed, and the time segment being evaluated represents the persontraveling by car. If the corporate policy is that employees do not usecell phones while driving, then this time segment is consideredunavailable for cell phone participation. (Preferably, whether anemployee is driving is derived from the calendar data. For example, acheck box may have been provided for the employee to indicate thisinformation on her calendar.)

Block 550 checks to see if there are any more free-time segments thatcan be evaluated. If so, control returns to Block 520 to process thenext time segment; otherwise, processing continues at Block 600 of FIG.6.

In FIG. 6, all free-time segments on this busy bar are processed to seeif, according to user preferences, the user really is available for thismeeting. For example, while working at home, the user might not beavailable for any travel, and thus should be considered unavailable forany in-person meetings. The processing of FIG. 6 operates in a similarmanner to the processing of FIG. 5, which handled corporate policyconsiderations. User preferences may also result in some free timesbeing marked as “preferred” times for the meeting (e.g., for the userwho prefers that meetings be scheduled at particular times of the day),with the result that when more than one possible meeting time is found,the preferred times may be chosen over other times or presented at thetop of a list of results for the person scheduling the meeting to choosefrom.

Block 600 begins the application of user preferences by checking to seeif there are any free times in this busy bar. If not, then controltransfers to Block 700 of FIG. 7. Otherwise, processing continues atBlock 610, which checks to see if this type of participation isallowable, according to this user's preferences. If not, then controltransfers to Block 650, which sets all time segments on this busy bar tobusy; control then transfers to Block 700 of FIG. 7. (Blocks 610 and 650are an optional optimization that may mark the busy bar as “all-busy”,based on user preferences, as an alternative to repeatedly loopingthrough each time segment. This optimization may be omitted withoutdeviating from the concepts disclosed herein.)

When this participation type is allowed, processing continues at Block620 where a free-time segment that has not yet been processed by thelogic of FIG. 6 is selected. Block 630 checks to see if this timesegment is allowable for scheduling the meeting, according to thisinvitee's user preferences. If not, then Block 640 marks the timesegment as busy and control transfers to Block 660. Recall thatuser-specific technological issues may be addressed under the generalcategory of user preferences. Thus, as an example, if this invitee'suser preferences indicate that she has access only to a low-speedconnection during this time segment but the meeting requirements callfor her to participate with a high-speed connection, then this timesegment is not allowable and Block 640 will mark it as busy.

If, on the other hand, the user preferences do not prevent the invitee'sparticipation during this time segment, then processing continues atBlock 670, which checks to see if the user preferences indicate thistime segment as being “preferred”. For example, this might be an earlymorning time segment but this invitee's preferences are for lateafternoon meetings. Depending on the outcome of the test at Block 670,Block 680 marks the time segment (e.g., using an associated bit settingor other indicator) as being preferred.

After the time segment has been processed, control reaches Block 660,which checks to see if there are any more free-time segments that havenot been processed. If so, then control returns to Block 620 to beginprocessing the next segment; otherwise, processing continues at Block700 of FIG. 7.

The processing of FIG. 7 begins by checking (Block 700) to see if allparticipation types for this person have been processed (i.e., whetherevaluation of all the busy bars is complete). If not, then controlreturns to Block 400 of FIG. 4 to begin processing the nextparticipation type. Otherwise, processing continues at Block 710.

In Block 710, the free-time segments for all of the allowableparticipation types are combined into a context-sensitive free-timelist, which represents this invitee's context-sensitive free time by anyof his allowed participation means.

Block 720 then checks to see if the calendars for all of the meetinginvitees have been analyzed. If not, control returns to Block 310 ofFIG. 3 to begin processing another invitee's schedule. Otherwise, Block730 searches through the free-time lists to find available time. Inpreferred embodiments, this search is performed using prior arttechniques, now that the free-time lists have been adapted usingtechniques of the present invention to more accurately represent eachperson's free time (in the context of that person's requiredparticipation level, user preferences, and so forth, as has beendescribed).

The search process performed at Block 730 may also search for a meetingfacility (e.g., a conference room). Techniques for searching throughavailable meeting facilities are known in the art, and may be used by animplementation of the present invention. Note that the person schedulingthe meeting may have requested one or more facility-specific features(e.g., see the audio visual equipment check box 125 on display panel 100of FIG. 1), and these requested features should be accommodated in theselection of meeting facility.

In preferred embodiments, an optional sorting operation is performed inBlock 740, which obtains sort preferences applicable to the personscheduling the meeting. These preferences may be obtained interactively(e.g., by prompting the meeting scheduler), or by retrievingpreviously-stored information from a repository, etc. Examples ofpreferences include how many choices for potential meetingtimes/locations should be presented at one time, whether the inviteenames should be presented in a particular order, whether the availablemeeting rooms should be ordered in terms of desirability (e.g., based onhow well they match the list of requested features). Related U.S. Pat.No. 7,096,232 (Ser. No. 09/875,556) describes use of filter and sortpreferences for a user submitting a query; refer to this related patentfor additional examples.

A particular meeting scheduler may have his/her own preferences forscheduling the meeting as well, such as choosing a location close tohis/her office or other physical location, or selecting a time near tosome other event, and may wish to see the possible meeting times sortedaccording to criteria of this type. Or, the meeting scheduler may chooseto see possible meeting times sorted according to when the meeting timeand/or location are most convenient for the maximum number of invitees,or perhaps for one or more selected invitees. (For example, the usermight select to have the meeting times/locations sorted to reflect theleast amount of travel required for the scheduler's manager, or a groupof high-level executives who will be attending, and so forth.)Optionally, the “preferred” status that was determined in Block 680 maybe used as a sorting criterion. For example, the meeting scheduler mightrequest for the results to be sorted according to his own preferredmeeting times, or according to the meeting times preferred by hismanager, or according to when the greatest number of invitee's preferredmeeting times can be accommodated, and so forth.

The results obtained in Block 730 are then sorted according to thecriteria requested by the scheduler, and returned (Block 750) fordisplay to the meeting scheduler. Processing will then continue at thepoint from which this processing has been invoked (Block 240 of FIG. 2,Block 940 of FIG. 9, or Block 1030 of FIG. 10, in preferredembodiments), and the sorted results will be displayed.

Turning now to the flowcharts in FIGS. 9-11, logic is illustrated thatdrives the free-time search process when a target location has not beenpre-specified (e.g., “Specific Location” was not selected in selectionbox 140 of FIG. 1) by the person scheduling the meeting. This processingbegins at Block 900 of FIG. 9, which is invoked from Block 230 of FIG.2, and passes to Block 910 which asks whether the person scheduling themeeting wants a meeting location to be selected/suggested beforebeginning the search process. As stated earlier, in environments wherethere are a large number of potential meeting locations and/or a largenumber of invitees, an exhaustive search may be time consuming, andtherefore performance may be improved by narrowing the possibilitiesbefore the search begins. If the test at Block 910 has a negativeresult, control transfers to Block 1000 of FIG. 10; otherwise,processing continues at Block 920 to begin evaluating choices for themeeting location that will be selected (or for multiple candidatelocations that will be suggested to the meeting scheduler).

At Block 920, the office location is determined for all meeting inviteeswhose in-person participation is required at this meeting. Block 930then determines a preferred meeting location based on where the officesare and one or more other selection criteria. Examples of criteria thatmay be used for selecting a preferred location include the following:minimize the number of users who will have to travel (e.g., try toschedule the meeting in the location where the majority of the in-personattendees will be located); find a central location where traveldistance, on average, will be minimized; minimize the travel distancefor one or more selected participants; and so forth. Any special meetingfacilities that have been requested are preferably also considered, suchas those represented by the wheelchair accessibility check box 130 inFIG. 1. Selecting a facility preferably comprises accessing a list ofmeeting facilities that (1) are available during the time frame in whichthe meeting is to be scheduled, (2) meet the selection criteriarequirements, and (3) have sufficient capacity for the number ofpotential in-person invitees. If multiple locations satisfy theserequirements, then the choices are preferably displayed to the personwho is scheduling the meeting, so that a single location can beselected. Alternatively, the free-time search may be conducted for eachsuitable location by iterating through the search process for eachcandidate location. (While this iteration is not reflected in theflowcharts, it will obvious to one of ordinary skill in the art how thelogic depicted therein may be modified to support this alternative.)

Once a location is selected, as shown in Block 940, thecontext-sensitive search is performed for this location by invoking theprocessing of FIGS. 3-7, described above. The results are then returned(Block 950) to the invoking logic (which in preferred embodiments isBlock 250 of FIG. 2).

FIGS. 10-11 represent the search process when the person scheduling themeeting has not pre-selected a specific location and has not selected alocation from the recommendation process in FIG. 9 (and Block 1000 istherefore reached following a negative result at Block 910). Block 1000begins the process by obtaining the list of meeting invitees whosein-person participation is required. A list of candidate locations isthen created in Block 1010. In preferred embodiments, the candidatelocations may be selected by compiling a list of (1) the officelocations for each invitee whose in-person presence is required; (2) alllocations for which calendar entries are already scheduled for thosepeople, for the time frame in which the meeting is to be scheduled;and/or (3) locations central to these in-person participant locations.Thus, consideration is given to where the invitees will be on the day ofthe meeting, to increase the likelihood of finding a meeting time andlocation. Alternatively, the candidate locations may be selected in animplementation-specific manner (e.g., using a list of site-specificpreferred locations or other criteria).

Block 1020 then chooses one of the candidate locations which has not yetbeen processed. Block 1030 performs the context-sensitive free-timesearch process for this candidate location, using the logic of FIGS.3-7. The results of the search are then saved (Block 1040), and Block1050 checks to see if there are any other candidate locations to beevaluated. If there are, then control returns to Block 1020 to selectthe next candidate. Otherwise, processing continues at Block 1060 wherethe results from evaluating each candidate location are combined, andprocessing then continues at Block 1100 of FIG. 11.

Block 1100 of FIG. 11 gets the sort preferences for sorting the searchresults. These preferences may be obtained by prompting the meetingscheduler, etc., as has been described with reference to Block 740 ofFIG. 7. The results are then ordered accordingly (Block 1110), andreturned (Block 1120) to the invoking logic (i.e., Block 250 of FIG. 2,in preferred embodiments) for display to the meeting scheduler.

FIG. 12 illustrates a sample GUI showing results of a search wheremultiple potential meeting times and locations were found. In thisexample, the meeting scheduler requested a meeting 60 minutes long, anddid not specify a particular location. The four meeting invitees areJohn, Sally, Paul, and Mary. Four different types of meetingparticipation are possible in this example, ordered from in-personparticipation to “as needed” participation. Thus, four busy bars areshown for each invitee. Bold font has been used in the legend to theleft of each busy bar to show which type of participation is allowablefor this invitee.

According to preferred embodiments, the busy bars presented to themeeting scheduler represent the invitee's actual availability forvarious types of meeting participation, including the impact of thepolicy considerations, user preferences, and so forth that are appliedduring operation of FIGS. 4-6. (Note that while Block 420 of FIG. 4selectively sets busy bars to “all-busy” for participation types thatare not allowable for each invitee, this all-busy status pertains onlyto the search process and is not used in preferred embodiments if thebusy bars are displayed.) The in-person busy bar is preferably displayedwith the computed location-sensitive travel times, which were determinedaccording to operation of Blocks 440-460 of FIG. 4. Showing eachinvitee's actual availability, in terms of free/busy-time segments, tothe person scheduling the meeting may enable him/her to make a betterdecision when selecting among the potential meeting times/locations.Furthermore, this information may assist in making a decision as towhether re-doing the search with different criteria is advisable.

In the example of FIG. 12, the meeting scheduler has selected the 9:30a.m. to 10:30 a.m. time segment on Apr. 9, 2002 in Bldg. 252, as shownin FIG. 12 by the highlighting at 1210. In the depicted representation,the topmost portion of the screen shows the potential meeting locationsand times (see element 1230), while the lower portion shows per-inviteebusy bars that reflect each invitee's availability for the location andtime that have been selected above (and, notably, travel times forattending the meeting in this particular location).

In the depicted example, the in-person busy bar for John shows that Johncan attend this meeting at the selected location because he has freetime between 9:30 a.m. and 10:30 a.m. and has 30 minutes available fortraveling to the meeting (between 9:00 a.m. and 9:30 a.m.). John alsohas free time on this day between 1 p.m. and 5 p.m., after having a busyperiod between 10:30 a.m. and 12:30 p.m. and then traveling for 30minutes (between 12:30 p.m. and 1:00 p.m.). John's presence is requiredin person (and therefore the displayed busy bar represents John'savailability for in-person participation at the meeting in Bldg. 252,and also shows that he has free time available later in the day duringwhich a meeting could alternatively be scheduled). Sally can attend inperson between 1:30 p.m. and 3:30 p.m., or between 8:30 a.m. and 4:30using a high-speed connection. Using other communication means, Sally isavailable up until 5:30 p.m. Paul and Mary have no time available forin-person participation on this particular day, but do have free timefor communicating by telephone and for participating in an as-neededbasis, as shown on those busy bars. According to the requirements placedby the meeting scheduler, participation for Sally, Paul, and Mary can bein-person or by high-speed connection; Paul is alternatively allowed toparticipate by telephone; and Mary is allowed to participatealternatively by telephone or by being available on an as-needed basis(e.g., via her pager). Thus, the context-sensitive free-time search ofthe present invention has determined that a 60-minute meeting whichmeets the requirements specified by the meeting scheduler, consideringthe required participation levels of each invitee and other factorsspecified as constraints, can be scheduled on April 9th between 9:30a.m. and 10:30 a.m. (in RTP Building 252), as shown in the “Recommendedmeeting times and Locations” display of FIG. 12 (and as represented inFIG. 12 by the depicted busy bars); alternatively, a 60-minute meetingfor these invitees and constraints can be scheduled on April 9th between1 p.m. and 4:30 p.m. (in RTP Building 5). Other recommended meetingtimes, dates, and locations are also shown (indicating that the meetingscheduler entered a range of allowable dates). If the meeting schedulerselects one of the candidate time periods which exceeds the duration ofthe meeting, then a window or screen (or other similar means) willpreferably be displayed to allow selecting a time period within thepermissible range. “Back” and “Next” arrows have been provided at thebottom of the sample display to allow the meeting scheduler to viewdetails of the busy bars for different days.

Upon clicking on the “Send Invitations” button 1220, invitations to eachinvitee will be programmatically generated and sent (e.g., by e-mail) toJohn, Sally, Paul, and Mary. As stated earlier, up to three invitationsmay be sent in preferred embodiments, including invitations thatrepresent travel time to and/or from the meeting for the in-personparticipants. Preferably, the invitations also convey the allowableparticipation levels, on a per-invitee basis, that have been specifiedby the meeting scheduler. The recipient may have to manually adjustexisting calendar entries and/or existing travel time segments.

As has been demonstrated, the present invention discloses advantageoustechniques for performing free-time searches that exploit information ofthe type used with electronic calendars. Meetings can therefore bescheduled more easily than in the prior art, where due to the additionalconsiderations that cannot be handled by current scheduler systems,there are many circumstances where meetings must be set up usingold-fashioned, time-consuming manual methods. By leveraging advancedcalendaring system information and using location, other contextinformation, and preferences to provide a complete picture of a person'savailability, as has been described herein, the present inventiongreatly increases the functionality (and therefore the value) ofscheduling systems, resulting in an ability to schedule meetings withmore accuracy and less rework.

While preferred embodiments have been described in terms of searchingfor time to schedule meetings, the disclosed techniques may be usedadvantageously for providing a general searching service in which thespecific meaning and/or use of the information differs from that whichhas been described above.

U.S. Pat. No. 5,790,974, titled “Portable Calendaring Device HavingPerceptual Agent Managing Calendar Entries”, discloses a portablecalendaring device for use by an individual. Calendar events can beadded without consideration of travel time. Travel times are thencomputed for the purpose of setting reminder alarms and advising theperson of schedule conflicts. This is done after the meeting has alreadybeen scheduled, and for only one person. The system is real-timeoriented, and can calculate travel times based on global positioningsatellite (“GPS”) coordinates of where the person is currently and usingreal-time feeds of traffic information.

Commonly-assigned U.S. Pat. No. 6,338,081, which is titled “MessageHandling Method, Message Handling Apparatus, and Memory Media forStoring a Message Handling Apparatus Controlling Program”, describes ameeting scheduling agent which schedules meetings for multipleparticipants and consults conference room availability as part of thescheduling process.

Neither of these patents discloses the inventive techniques of thepresent invention.

As will be appreciated by one of skill in the art, embodiments of thepresent invention may be provided as methods, systems, or computerprogram products. Accordingly, the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment, oran embodiment combining software and hardware aspects. Furthermore, thepresent invention may take the form of a computer program product whichis embodied on one or more computer-readable storage media (including,but not limited to, disk storage, CD-ROM, optical storage, and so forth)having computer-readable program code embodied therein.

The present invention has been described with reference to flowchartillustrations and/or flow diagrams of methods, apparatus (systems), andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orflow diagrams, and combinations of blocks in the flowchart illustrationsand/or flows in the flow diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, embedded processor, or other programmable data processingapparatus to produce a machine, such that the instructions, whichexecute via the processor of the computer or other programmable dataprocessing apparatus, create means for implementing the functionsspecified in the flowchart and/or flow diagram block(s) or flow(s).

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart and/or flowdiagram block(s) or flow(s).

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart and/or flow diagram block(s) or flow(s). Furthermore, theinstructions may be executed by more than one computer or dataprocessing apparatus.

While preferred embodiments of the present invention have beendescribed, additional variations and modifications in those embodimentsmay occur to those skilled in the art once they learn of the basicinventive concepts. Therefore, it is intended that the appended claimsshall be construed to include all such variations and modifications asfall within the spirit and scope of the invention.

1. A computer-implemented method of scheduling a meeting, furthercomprising steps of: selecting one or more meeting invitees; selecting,for each invitee, an allowable participation level; evaluatingavailability information for each invitee, with reference to theallowable participation level; and using results of the evaluating stepfor all invitees to determine when the meeting can be scheduled.
 2. Themethod according to claim 1, wherein the allowable participation levelfor each invitee is a minimum required participation level, and whereinthe evaluating step evaluates the availability information for eachinvitee for the minimum required participation level and for zero ormore higher-ranking participation levels which are implied by theminimum required participation level.
 3. The method according to claim1, wherein the selecting step selects one or more explicitly-specifiedparticipation levels for each invitee, and wherein the evaluating stepevaluates the availability information for each invitee for each of theone or more explicitly-specified participation levels of that invitee.4. The method according to claim 1, wherein the using step furthercomprises the step of determining one or more candidate meeting timeswhen all invitees are available according to the evaluating step.
 5. Themethod according to claim 1, further comprising the step of consideringa meeting location supplied by a meeting scheduler as a constraint onwhen the meeting can be scheduled.
 6. The method according to claim 1,further comprising the step of considering one or more meetingpreferences supplied by a meeting scheduler in determining when themeeting can be scheduled.
 7. The method according to claim 1, furthercomprising the step of presenting the results of the evaluating step toa meeting scheduler.
 8. The method according to claim 7, furthercomprising the step of allowing the meeting scheduler to select fromamong a plurality of potential times and/or locations in the presentedresults.
 9. The method according to claim 8, further comprising the stepof sending meeting invitations to the invitees wherein the meetinginvitations specify the selected time and location.
 10. The methodaccording to claim 9, wherein the meeting invitations further specifytravel time to and/or from the selected location for those invitees forwhom in-person participation is an allowable participation level. 11.The method according to claim 9, wherein the meeting invitations furtherspecify one or more allowable participation levels for each meetinginvitee.
 12. A computer program product for scheduling a meeting, thecomputer program product embodied on one or more computer-readable mediaand comprising: computer-readable program code means for selecting oneor more meeting invitees; computer-readable program code means forselecting, for each invitee, an allowable participation level;computer-readable program code means for evaluating availabilityinformation for each invitee, with reference to the allowableparticipation level; and computer-readable program code means for usingresults of the evaluation for all invitees to determine when the meetingcan be scheduled.
 13. The computer program product according to claim12, wherein the allowable participation level for each invitee is aminimum required participation level, and wherein the computer-readableprogram code means for evaluating further comprises computer-readableprogram code means for evaluating the availability information for eachinvitee for the minimum required participation level and for zero ormore higher-ranking participation levels which are implied by theminimum required participation level.
 14. The computer program productaccording to claim 12, wherein: the computer-readable program code meansfor selecting an allowable participation level for each invitee isreplaced by computer-readable program code means for specifying, foreach invitee, one or allowable participation levels; and thecomputer-readable program code means for evaluating availabilityinformation for each invitee operates with reference to the one or morespecified allowable participation levels.